The issue I found is that if close is called the next request will try to open a TCPSocket.

Wait what? That sounds like a big foot gun right there. I think calling close should make the HTTP::Client instance unusable, regardless of this change.

Tests? :)

Also documentation of this method, and maybe an embedded example 🙇

I had actually thought about this some time agoe. But it couldn't work without #9210.
It makes sense to use an IO directly and I suppose this could also continue when #6011 is resolved. Although most use cases should probably be served by that.

As @jhass mentioned, the #close behaviour needs to be fixed. IMO it would probably be best to close the client completely and not be able to reconnect. That would be a breaking change, though. So maybe for now we could just set a flag on the new initializer which disables automatic socket creation.

Why can't we make breaking changes when we release 1.0.0? In my mind that release sounds like the biggest breaking change ever so that later there are no breaking changes.

We can make breaking changes, but those might not have good time of deprecation notice. I wouldn't avoid doing it anyway if we think it's worth it.

I think this wouldn't be a huge breaking change, as being able to reuse a closeed HTTP::Client feels like it ought to be against expectations anyways.

The socket is re-created because the api can be used like this:

HTTP::Client.new(...) do |client|
  client.get ...
  client.post ...
end

Within the block the connection might be the same or not, depending on wether the server/protocol supports the keep alive. Or the connection might be a different one, if a connection pool were implemented.

Then the close method is available, so the same behaviour can be obtained when the block syntax can't be used. Maybe we can differentiate an internal close or just set an internal flag to allow re-creation of the connection. That would work as @straight-shoota suggest. And also I don't think it's a big breaking change except for those explicitly calling close but still reusing the client instance.

I just implemented what @straight-shoota suggested, disabling autoreconnection only when initialized with IO, so this shouldn't be a breaking change. Also added specs and docs. We can still change how close works if we want, but I would do it in a separate PR. Note that we currently even have that behaviour documented:

Should we change the name of the instance var? @socket -> @io

We can still change how close works if we want, but I would do it in a separate PR.

Na, I wouldn't touch that until the entire HTTP::Client implementation gets revisited.

It's on my to-do-after-1.0 list. But the list is actually quite long. 😆

Ideally, when using with an IO the client should not set a default host header unless explicitly asked told. The current default localhost:80 is just an arbitrary value and may cause issues if the server tries to read something from that.
I guess it's probably fine for now, though. Changing that would require a lot more refactoring.

The Host header is mandatory in HTTP/1.1 and the client defaults to that version on every request. It's normally used only for virtual hosts so at most I think it would trigger a 404.

If you have ideas for the HTTP::Client post 1.0 I suggest we review them now, at least to tune the API to avoid breaking changes after the release. I'd love to see a more flexible HTTP client built-in in the std, but I don't have specific plans in mind.

Correction: according to the RFC, seems like the Host header is indeed mandatory, but it must be empty in those cases: https://tools.ietf.org/html/rfc2616#section-14.23. Setting @host = "" might work for now. I'll add that to this PR.

Yes, the host header is mandatory, but it should be empty if there's no meaningful value.

My ideas about HTTP::Client are basically expressed in #6011 and related discussions. There's also a PoC implementation in
#6001 and judging by that I'm relatively confident that we can change and enhance the implementation without breaking the public API, at least with temporary re-implementations to keep backwards compatibility.

I think another thing that should happen is to have HTTP::Client.get and others use an internal pool of connections. So in general people shouldn't use HTTP::Client.new at all. (similar to Go, I guess)

@asterite Yes, that's actually one of the main features described in #6011

Well.. finally I renamed the ivar 🙈

Just a note that the old annotation, @socket : TCPSocket | OpenSSL::SSL::Socket | Nil, actually was already @socket : IO | Nil because TCPSocket and OpenSSL::SSL::Socket both inherit from IO so that was the actual type seen by the compiler.

I'd still like #9052 to be considered because it would fix that problem (the ivar would actually be that union type, never go to the parent type).